As businesses increasingly rely on computers for their daily operations, managing the vast amount of business information generated and processed has become a significant challenge. Most large businesses have a wide variety of application programs managing large volumes of data that is entered and/or provided to users via many different types of input/output devices. As an example, in the banking industry, data may be provided using a variety of devices, such as an Automated Teller Machine (ATM) key entry pad, a magnetic card reader, a receipt printer, a passbook reader/writer, and so on. These input/output devices may be available via various types of networks and operating system platforms and often include a variety of devices produced by many different vendors. Each device typically is incompatible with the devices of other vendors.
Often, vendors of input/output devices provide their own application programming interfaces (APIs, sometimes referred to as application program interfaces) and/or command line utilities for using the specialized features of their own input/output devices, but these APIs and command line utilities are not compatible from vendor to vendor. Instead, these APIs and command line utilities typically communicate in a device-specific native language. Furthermore, device communication standards have not been widely adopted, adding to the incompatibility problem.
One approach to communicating with a wide variety of types of devices is to modify an enterprise data management application that uses the features of these devices to communicate in the device-specific native language for each device. For example, to add a new type of input/output device to an enterprise data management system environment, the enterprise data management application often must be modified to call the device-specific APIs in addition to adding a new device driver or modifying an existing device driver. The software using the new device is tested by enterprise data management application vendor personnel and incorporated into a later release of the enterprise data management application.
This process for making new devices available has proven costly for vendors of enterprise data management applications, as support for each new type of device requires a new release, a costly and time-consuming project. Furthermore, the release process has proven untimely for the vendors of devices, as support for their products depends upon the release schedules for enterprise data management applications in which their products are used, slowing time to market for their devices. Typically, enterprise data management application vendors are not device vendors and would prefer a platform- and device-independent mechanism to request input/output services.
Another approach to simplify communication with a variety of different devices is provided by the Microsoft Windows Driver Model (WDM). WDM was introduced to allow driver developers to write device drivers that are source-code compatible across all Microsoft Windows operating systems. A Windows driver acts as an intermediary between an application program and a device driver. A Windows driver API is pre-defined to receive calls from application programs for services, and the Windows driver determines the appropriate device to provide the service and communicates with the selected device in that device's native language.
The Windows Driver Model, however, has failed to provide the flexibility needed by enterprise data management applications. Because the WDM API is pre-defined, all features provided by each device may not be supported. In addition, most API calls do not provide optional variables that can be set to take advantage of a particular device's features, and no mechanism exists to easily modify messages sent to the WDM API. As a result, it may not be possible to take advantages of the particular features of a device without using the device-specific native language.
What is needed is the ability to dynamically add or modify support for a device in an enterprise data management application without the need to modify the enterprise data management application to communicate with the device.